The invention is related to user interfaces where, for example, a long press of a button is used to perform a different function from a short press. Using a single button instead of multiple buttons to accomplish more than one functionality presents a very significant opportunity to reduce the hardware features of devices, especially small devices like wireless phones.
For example, consider the backspace key on a typical computer keyboard. Pressing it briefly will delete a single character, but if the backspace key is held down during a slight lapse of time, then the key suddenly begins to delete multiple characters continuously. Other examples include pressing and holding a button for moving clock hands continuously in a wristwatch, or pressing and holding a right key to initiate speech recognition in various mobile phones.
In many user interfaces with limited mechanisms for input (e.g. mobile phones), utilization of the few buttons available is enhanced by separating a short press of a button from a press where the button is held for a longer duration (the duration being preset by the device designer). Sometimes this works very nicely if the functionality occurring from the long key press is a natural extension of the functionality occurring from a short press. For example, it is natural to press and hold the delete button on a PC keyboard to delete many characters. In that case, the long keypress optimizes the user interface (UI) so that it requires fewer keypresses, and also so that the user interface does not require one button for single character deletion and another button for multiple character deletion.
However, when the function resulting from the long keypress is not obvious, and is an alternative to the function resulting from a short keypress, then the user of a prior art device often needs to guess what will happen. Furthermore, the long keypress is often a hidden feature in the user interface, and therefore the long keypress may be left unused. Frequently, the prior art provides no hint to the user that there is an extra alternative functionality that can be accessed by keeping the button pressed. Thus, users are often unaware of their options, especially when the function is a rarely used one (e.g. accessing the list of running tasks by long-pressing an applications key), or when the long press is used as a shortcut to a functionality that can also be reached by navigating through a more elaborate unhidden route in the UI. Style guidebooks often mention that the long-press should be used only when it is a natural extension of a short press, but in practice this rule is often breached.
It is known to hold a button down for a period of time in order to perform a function, such as turning off a device, and it is also known to preface this function by informing the user what will happen if the user continues to hold down the button. For example, a button can be held down, thus causing a progress bar to appear, and once the progress bar is full then the device shuts down. However, this type of device only describes one possible action resulting from release of the button (i.e. shutting down), and releasing the button prematurely causes no action at all. Thus, holding the button down is merely a way of ensuring that the user will not shut off the power unless the user is very certain that he wants the device to shut down, and this technique does not facilitate any actions in addition to shutting down. (The word “action” in this application excludes the do-nothing option.)
It is also known for a user to contact different touch-sensitive buttons in order to explore their functionality before actually pressing those buttons to activate them. See Hinckley et al. (U.S. Pat. No. 6,456,275). However, that technique would not significantly help a user to be aware that a transition (i.e. time-out) from one function to another is nearing, and furthermore that technique would require the user to remember which functionality corresponds to which period of time.
It is further known in the prior art to use soft keys (e.g. buttons that appear on a display screen), in a tap-and-hold manner. For example, an item on a menu can be selected, and a mouse button can be held down until the user selects a desired functionality, and then the user chooses that functionality by releasing the mouse button. Unfortunately, this type of scenario does not offer any advantage for a hard button (i.e. a physical key as distinguished from a soft key). Moreover, even for soft keys, this type of tap and hold scenario will not work if the device lacks a mouse or other similar device.